The number of dynamic test points is the sum of the number of test points per function in relation to dynamically measurable quality characteristics. The number of test points is based on two types of factors:

• function-dependent factors (D_f)
• factor representing the dynamically measurable quality characteristics (Q_d).

The FPA function is used as a unit of function. When determining the user importance and intensity of use, the focus is on the user function as a communication resource. The importance the users attach to the user function also applies to all of the underlying FPA functions.

FUNCTION-DEPENDENT FACTORS

The function-dependent factors are described below, including the associated weights. Only one of the three described values can be selected (i.e. intermediate values are not allowed). If too little information is available to classify a certain factor, it must be given the nominal value.

User importance

User importance is defined as the relative importance the user attaches to a specific function in relation to the other functions in the system. As a rule of thumb, around 25% of the functions must be in the category “high”, 50% the category “neutral”, and 25% in the category “low”. User importance is allocated to the functionality as experienced by the user. This means allocation of the user importance to the user function. Of course, the user importance of a function must be determined in consultation with the client and other representatives of the user organisation.

Weight:

• 3 - low: the relative importance of the specific function in relation to the other functions is low
• 6 - Neutral: the relative importance of the specific function in relation to the other nfunctions is neutral
• 12 - high: the relative importance of the specific function in relation to the other functions is high.

Intensity of use

Intensity of use is defined as the frequency at which a certain function is used by the user and the size of the user group that uses that function. As with user importance, intensity of use is allocated to functionality as experienced by users, i.e. the user functions.

Weight:

• 2 - low: the function is executed by the user organisation just a few times per day or per week
• 4 - neutral: the function is executed by the user organisation many times per day
• 8 - high: the function is executed continuously (at least 8 hours per day).

System impact

System impact is the level at which a mutation that occurs in the relevant function has an impact on the system. The level of impact is determined by assessing the logical data collections (LDCs) to which the function can make mutations, as well as the number of other functions (within the system boundaries) that access those LDCs. The impact is assessed using a matrix that shows the number of LDCs mutated by the function on the vertical axis, and the number of other functions accessing these LDCs on the horizontal axis.

A function counts several times in terms of impact when it accesses multiple LDCs that are all maintained by the function in question.

Explanation: L = Low impact, M = Medium impact, H = High impact.

If a function does not mutate any LDCs, it has a low impact. A CRUD matrix is very useful when determining the system impact.

Weight:

• 2 - the function has a low impact
• 4 - the function has a medium impact
• 8 - the function has a high impact.

Complexity

The complexity of a function is assessed on the basis of its algorithm. The global structure of the algorithm may be described by means of pseudo code, Nassi-Shneidermann or regular text. The level of complexity of the function is determined by the number of conditions in the algorithm of that function. When counting the number of conditions, only the processing algorithm must be taken into account. Conditions resulting from database checks, such as validations by domain or physical presence, are not included since they are already incorporated implicitly in the function point count.

As such the complexity can be determined simply by counting the number of conditions. Composite conditions, such as IF a AND b THEN count double for complexity. This is because two IF statements would be needed without the AND statement. Likewise, a CASE statement with n cases counts for n-1 conditions, because the replacement of the CASE statement by successive IF statements would result in n-1 conditions. In summary: count the conditions, not the operators.

Weight:

• 3 - a maximum of 5 conditions are present in the function
• 6 - 6 to 11 conditions are present in the function
• 12 - more than 11 conditions are present in the function.

Uniformity

In three types of situation, a function counts for only 60%:

• A nearly unique function occurring a second time – in this case, the test specifications that are to be defi ned can be largely reused.
• Clones – in this case, too, the test specifications that are to be defined can be reused.
• Dummy functions – but only if reusable test specifications for the dummy exist.

The uniformity factor is given the value 0.6 if one of the above conditions is met, otherwise it is given the value 1.

In an information system, there can be functions that have a certain level of uniformity in the context of testing, but are marked as unique in the function point analysis. In the function point analysis, being unique means:

• A unique combination of data collections in relation to the other input functions.
• Not a unique combination of data collections, but another logical processing method (e.g. updating a data collection another way).

In addition, there are functions in an information system that are said to be fully uniform in the context of function point analysis and are therefore not allocated any function points, but must be counted in the testing because they do require testing. These are the clones and dummies.

Calculation method

The factor (D_f) is determined by establishing the sum of the values of the first four function-dependent variables (user importance, intensity of use, system impact and complexity) and dividing it by 20 (the nominal value). The result of this calculation must then be multiplied by the value of the uniformity factor. The D_f factor is determined per function.

D_f = ((Ui + Iu + Si + C) / 20) * U

• Df = weight factor of the function-dependent factors
• Ui = user importance
• Iu = intensity of use
• Si = system impact
• C = complexity
• U = uniformity

Standard functions

If functions for error messages, help screens and/or menu structure are present in the function point count – which often is the case – they must be valued as follows:

(In this example, it is assumed that the valuation of the factors system impact and complexity are identical for the FPA functions in a user function).

• functionality
• security
• effectivity/suitability
• performance
• portability.

The weight of the quality requirements must be valuated for each quality characteristics in the context of the test to be executed, by means of a score, possibly by sub-system.

Weight:

• 0 - not important – not measured
• 3 - low quality requirements – attention must be devoted to it in the test
• 4 - regular quality requirements – usually applicable if the information system relates to a support process
• 5 - high quality requirements – usually applicable if the information system relates to a primary process
• 6 - extremely high quality requirements.

The quality characteristics that are measured dynamic explicit have the following weight factors:

• Functionality - 0.75
• Security - 0.05
• Effectivity - 0.10
• Performance - 0.05
• Portability - 0.05

Which relevant quality characteristics (distinguished in the test strategy) will be tested dynamic implicit must be determined. A statement about these quality characteristics can be made by collecting statistics during test execution. E.g. performance can be measured explicitly, by means of a reallife test, or implicitly, by collecting statistics.

The quality characteristics to be measured dynamic implicit must be specified. The number of quality characteristics can then be determined. The weight is 0.02 per characteristic for Qd. In principle, every quality characteristic can be tested dynamic implicit.

Calculation method (Q_d)

The score given to each dynamic explicit measurable quality characteristic is divided by four (the nominal value) and then multiplied by its weight factor. The sum of the figures obtained this way is calculated. If certain quality characteristics were earmarked for dynamic implicit testing, the associated weight (0.02 per characteristic) must be added to the above sum. The figure obtained this way is the Q_d factor. Usually, the Q_d factor is established for the total system once. However, if the strategy differs per sub-system, the Q_d factor must be determined per sub-system.

Calculation example 2 - Determining the dynamically measurable quality characteristics (Q_d)

The following are measured dynamic implicit:

Performance = 0.02

Efficiency = 0.02

Maintainability = 0.02

Q_d = 0,94 + 0,05 + (3 * 0,02) = 1,05

FORMULA FOR DYNAMIC TEST POINTS

The number of dynamic test points is a sum of the number of test points per function. The number of test points per function can be established by entering what is now known in the formula below:

TP_f = FP_f * D_f * Q_d

TP_f = the number of test points per function
FP_f = the number of function points per function
D_f = weight factor of the function-dependent factors
Q_d = weight factor of the dynamic quality characteristics

Calculation example 3 - Calculation of total number of dynamic test points (ΣTP_f)